see #1055 for some prior (sparse) discussion.
I decided not to merge that PR and instead try to add config options to MT for all corresponding jaeger options.
This didn't go well because jaeger doesn't simply use a list of config values with corresponding defaults. certain defaults are being set after inspecting certain other variables
i also found some of the config options in jaeger not very well named, or there were some inconsistencies with booleans, i don't remember the details right now.
It's frustrating that this has been dragging on so long, and i want to merge this, but i want to look into this a bit more.
In particular, we can just give up on mapping directly to the jaeger options, but we should still lay out our options such that they support the different sampling mechanisms (we want to use the remote controlled one)

That sounds fine but this is something we desperately needed on our side. Jaeger was dropping more spans than not, making it useless. So, it was either dedicate nearly 15% of our resources to jaeger, or sample a little bit (we sample 5%). It's worked out very well for us.

More config options will add complexity a little bit. I can't say I looked into all the options in jaeger, since probabilistic sampling was all I needed.

That sounds fine but this is something we desperately needed on our side

understood. we'll support the functionality, just want to have another look at a generic way to configure the jaeger client

i just submitted #1341 which I think is the better way to support this.